home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000114-20000217 / 000147_news@columbia.edu _Wed Jan 26 09:57:56 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA12796
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 Jan 2000 09:57:56 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA12359
  7.     for kermit.misc@watsun.cc.columbia.edu; Wed, 26 Jan 2000 09:47:41 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: Case Study #10: Atomic File Movement
  11. Date: 26 Jan 2000 14:47:39 GMT
  12. Organization: Columbia University
  13. Message-ID: <86n1eb$c24$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <86llha$40u$1@news.value.net>,
  17. Mark Sapiro  <msapiro@value.net> wrote:
  18. : Frank posted a tutorial on the features in C-Kermit for "atomic"
  19. : file movement.
  20. : 
  21. : I won't quote it here as it is readily available at
  22. : http://www.columbia.edu/kermit/case10.html
  23. : 
  24. : It seems to me however, that there must still be a window, albeit
  25. : a small one during which a connection can be lost and the sender
  26. : will believe the file has been successfully sent and the receiver
  27. : will not or vice versa.
  28. : 
  29. : I don't know the details of the protocol well enough to know exactly
  30. : what scenario can occur, but I assume the sender sends a "file complete"
  31. : packet of some kind.  Perhaps this packet gets lost when the connection
  32. : goes down.  The sender may assume the file is successfully sent, but
  33. : the receiver doesn't know it.
  34. : 
  35. : Or perhaps the sender needs an ACK to this packet which the receiver
  36. : sends and this is the packet that is lost.  Then the receiver knows
  37. : it has received the whole file, but the sender doesn't.
  38. : 
  39. : Am I missing something here, or is this a problem?
  40. : 
  41. As Joe explained, the file sender sends an End-of-File (Z) packet after
  42. the end of the file.  So the sender knows the whole file was sent.
  43.  
  44. The file receiver might or might not get the Z packet.  If the Z packet
  45. does not arrive, the protocol times out and recovery action is taken;
  46. ultimately the Z packet is retransmitted until an affirmative response
  47. is received, or the retranmission limit is exceeded, or the connection
  48. is observed to be broken.  In any of these failure cases, the sender
  49. knows the transfer was not successful, and therefore does not delete,
  50. move, or rename the source file.
  51.  
  52. Once the file receiver gets the Z packet, it acknowledges it.  The file
  53. sender might or might not get the acknowledgement.  If it doesn't, the
  54. protocol times out and recovery action is taken.  If the recovery action
  55. fails, the sender does not know if the transfer was successful, and
  56. therefore does not delete, move, or rename the source file.
  57.  
  58. If the sender receives the acknowledgement, it knows that the receiver got
  59. the whole file, and so it can delete, move, or rename it.
  60.  
  61. Therefore, any error condition -- including loss of connectivity --
  62. triggers the conservative response: keep the source file.  It is better to
  63. send it more than once than less than once.  By design, the protocol might
  64. seem to fail when it succeeds, but it should never seem to succeed when
  65. it fails.
  66.  
  67. By the way, what makes Kermit somewhat immune to the two-armies problem,
  68. also known as the three-way-handshake problem, is that the Z packet and
  69. its ACK are not the final stage of Kermit protocol; the file receiver does
  70. exit the protocol or close the connection after acknowledging the Z
  71. packet.  In fact, the whole protocol is protected by an "outer layer" that
  72. has no consequences at the file level.  If this outer layer is disturbed
  73. at the end (in the typical case, by premature disconnection) there might
  74. be an annoying delay, but no harm is done.
  75.  
  76. - Frank
  77.  
  78. P.S. I should have mentioned in the original posting that the rename
  79. operation does not work across physical disks in operating systems such
  80. as Unix; this was corrected in the web-page version.